Client/Server computing first became fashionable in the 1960's as a good method of providing many users of small machines (clients) access to data maintained by large systems (servers), the data being maintained in a database. A typical client/server architecture is one in which the client accesses the server through middleware. In this architecture the client is fairly simple and uses applications that run in a server and the middleware handles the complexities of, for example, client/server communication and transaction management. This enables the application writer to concentrate on client and application functionality whilst the middleware takes care of the rest. However, one problem that developed in this architecture was that many middleware products came to the market each providing different functions and different interfaces to those functions. As a result client and application code had to be written to interface with a particular middleware product and could not easily be ported between different middleware products. Further the clients written for one middleware product could not access applications written for a different middleware product.
In order to solve this problem the middleware industry started to look into specifying a standard middleware architecture and interface. There have been several attempts at this and one such attempt was the Common Object Request Broker Architecture (CORBA) which was first published in 1991. However whilst CORBA has been successful and implemented in several middleware products it has been largely superseded by the Enterprise JavaBeans architecture which provides a method of making JavaBeans applications available in a distributed client/server environment. (JavaBeans is a registered trademark of Sun Microsystems Inc.)
The first EJB specification was published in March 1998 and was the culmination of several years work between Sun Microsystems Inc. and partner companies, such as IBM, Oracle and Hewlett Packard. From this date there have been many implementations of EJB server products and much has been written about the subject. Indeed most aspects of EJB could now be considered well known and well researched by those skilled in art. From this early specification there are now several specifications each relating to different aspect of EJBs, such as the Java 2 Enterprise Edition (J2EE) specification, the J2EE Connector Architecture (JCA) specification and the Java Message Service specification (J2EE is a trademark of Sun Microsystems Inc.).
The J2EE specification defines a standard for developing multi-tier enterprise applications, particularly in web based environments. The JCA specification defines an architecture for providing connections to existing enterprise information systems (EIS) and JMS defines an interface for providing connections to messaging systems.
The JCA specifies two aspects of EIS support, the first (server) aspect is implemented by the application server and specifies how the application server integrates an EIS provider into the server thereby providing, for example transactional and security facilities, whilst the second (resource adapter) aspect is implemented by the EIS provider and specifies interfaces which the EIS provider must provide in order to be integrated by the first aspect. The JMS, on the other hand, only specifies one aspect which describes the interfaces the messaging system must provide in order to be accessible to an application. The JMS does not specify an architecture by which this can be integrated into the facilities of the application server.
Although the function of the resource adapter aspects of JCA and JMS are quite similar in that they provide connections to other systems, their requirements are quite different. For example a JCA resource adapter must provide JCA interfaces for the JCA server aspect to call whereas the JMS does not. Further a connection to an EIS has transactional context and associated security credentials and provides an application with means to communication with the EIS. A JMS connection to a messaging system, however, has only associated security credentials and the application must further obtain a session, as part of the connection, in order to communicate with the messaging system, the session having a transactional context. As a result of these differences a JMS cannot be integrated into the application server using the server aspect of the JCA. Instead the application server provider must define how this is done, and this leads to provider specific solutions.